home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 58 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.4 KB
  1. Date: Mon, 30 May 1994 20:48:27 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Colour. 
  4. To: gem-list@world.std.com
  5. In-Reply-To: <9405310029.AA11953@uqcspe.cs.uq.oz.au>
  6. Message-Id: <Pine.3.87.9405302027.C18554-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10. Ah, yes.  I like that suggestion.
  11.  
  12. If the color manager were another GEM app under MultiTOS, then it would 
  13. receive all of the WM_TOPPED messages and it could handle all or the 
  14. color changes automatically.
  15.  
  16. When an app wanted to assign a palette to a WINDOW (not an app), it would 
  17. tell the manager that when that window is topped, to use the palette 
  18. assigned to that window.
  19.  
  20. For apps that didn't follow the rules, when the manager it first loaded, 
  21. it would get the default palette and when an unassigned window is topped, 
  22. it would use the default palette.
  23.  
  24. Other options include things like automatic palette handling.  When a 
  25. window is topped, the manager would assign the current palette to the 
  26. window that used to be on the top, then set the palette last assigned to 
  27. the new top window.  This way, next time the window is topped, the 
  28. palette that was active when it was last on top will be automatically set 
  29. again and the app would never even have to care or register or follow 
  30. anything but the simplest of rules (like don't change palette unless your 
  31. window is on top).
  32.  
  33. Also, palettes should be in VDI format... values of 0 to 1000 for system 
  34. independance.
  35.  
  36.  
  37.